Method and Apparatus for Creating Binary Attribute Data Relations

ABSTRACT

The present invention advances the prior art of the content menu, an end-user database interface which organizes relational data according to the data and data relations from in the database. It does this by disclosing how to deploy the Binary Attribute Relation or BAR as meta-query data, and by disclosing how Binary Attribute Data Relations or BADR are derived from the BAR query, a primitive retrieval operation. All three new concepts: the BAR, the BADR, and the BAR query, are compact in a mathematical sense, as they represent each of their respective subject material in the most fundamental or primitive way, not matter whether it is a unit of meta-query data, data relations, or the query statement on which they are derived. These developments advance the art of the content menu, most notably with the art of its authoring system, by adding new flexibility to its functionality, as in the case of its runtime list menus, by making the authoring system more well integrated and easier to maintain, and by laying the foundation for extending its capabilities to handle other types of data models and data structures.

References Cited 6,301,583 Oct. 9, 2001 Zellweger 6,279,005 Aug. 9, 2001Zellweger 6,243,700 Jun. 5, 2001 Zellweger 6,131,100 Oct. 10, 2000Zellweger 6,131,098 Oct. 10, 2000 Zellweger 6,061,692 May 9, 2000Thomas, et al. 5,664,173 Sep. 2, 1997 Fast 5,630,125 May 13, 1997Zellweger

REFERENCES

-   Abiteboul, Serge, Richard Hull, and Victor Vianu, Foundations of    Databases. Reading, Mass.: Addison-Wesley Publishing Company,    1994, p. 37.-   Atzeni, Paulo, Stefano Ceri, Stafano Paraboschi and Riccardo    Torlone. Database Systems, Concepts, Languages, and Architectures.    Berkshire, England: McGraw-Hill Publishing Company, 2000, pp. 21-22.-   Biggs, Norman. Discrete Mathematics. Oxford, England: Oxford    University Press, 1996, p. 194.-   Burgin, Mark. “Theory of Names Sets as a Foundational Basis for    Mathematics” in Diez, A., J. Echevarria, A. Ibarra (eds.)    “Structures in Mathematical Theories, Reports of the International    Symposium.” Universidas del Pais Vasco: Sep. 25-29, 1990, p 417.-   Codd, E. F. A Relational Model of Data for Large Shared Data Banks.    Communications of the ACM, 13(6), 1970, pp. 377-387.-   Codd, E. F, Extending the Database Relational Model to Capture More    Meaning, ACM Transactions on Database Systems, 4(4), 1979, pp.    397-434.-   Date, C. J. An Introduction to Database Systems. Eighth Edition.    Boston, Mass.: Addison-Wesley, 2004, p. 274.-   Date, C. J. Logic and Databases, the Roots of Relational Theory.    Victoria, BC Canada: Trafford Publishing, 2007, p. 377.-   Knuth, D. The Art of Computer Programming, v. 2: Seminumerical    Algorithms, Boston, Mass.: Addison-Wesley, 1997, p. 348.-   Newell, Allen and Herbert Simon, “Computer Science as Empirical    Inquiry: Symbols and Search, Communications of the ACM, March 1976,    19, 3, pp. 113-126.-   Zellweger, Paul. A Database Taxonomy Based On Data-Driven Knowledge    Modeling. (IEEE) KIMAS'05 Waltham, Mass., pp. 469-474.

BACKGROUND

In 2000, Zellweger (U.S. Pat. No. 6,131,098) introduced a novel way tonavigate over database content using a content menu, a databaseinterface which organizes data and data relations found in the database.These data relations takes the form of an open hierarchical datastructure (OHDS), a list of nested lists, first described by Zellweger(U.S. Pat. No. 5,630,125) in 1997. The OHDS is similar to the “[LEFTchild-RIGHT sibling]” data structure described by Knuth, but Zellweger'simplementation of it goes well beyond the simple functionality of memorymanagement tool. Having its own dedicated GUI, and a comprehensive toolset for managing data-topic lists, the OHDS manages menu data for thecontent menu, by enabling menu developers to add menu topics either byhand, by automated mapping algorithms that extract data and datarelations from the database, or by both methods.

Over the past decade, the construction of the OHDS served as aconceptual framework for improving the techniques used to support thecontent menu. The mapping algorithm used to build the OHDS is recursive.Each recursive call extracts a list of data-topics from a database andthen adds it to a leaf node in the OHDS. This construction pattern issimilar to the tree-growing methodology described by Biggs which mimicsthe depth-first search, by systematically branching out from each leafnode at the bottom of the structure. By carefully observing theseoperations, the OHDS provided an opportunity for seeing how runtimedata-topic lists could be added to the content menu, along with numerousother improvements, including U.S. Pat. No. 6,234,700 and U.S. Pat. No.6,301,583.

Early on Zellweger was able to show how to automatically generate anetwork of data-topic lists for the OHDS using a dedicated interactivemenu (U.S. Pat. No. 6,131,100) and specialized software (U.S. Pat. No.6,279,005). In U.S. Pat. No. 6,131,100, a newly disclosed GUI enables amenu developer to navigate over a target database and to create a seriesof “logical” relationships between database attributes which could berepresented by a symbolic expression. Program logic disclosed by U.S.Pat. No. 6,279,005 shows how to parse this expression to capturemeta-query data, which could then be used to extract lists ofdata-topics from a target database. Improvements to these advancesinclude U.S. Pat. No. 6,131,098 which parses the symbolic expression andthen stores this meta-query data in its own structure, thereby enablingthe same meta-query data to be used either to generate a OHDS for thecompiled menu data files or to a create list menu in the content menu atruntime.

The current disclosure introduces a number of new improvements over allthis prior art by now focusing on how different types of data relations,identified here as Binary Attribute Data Relations or BADR, contributeto the construction of the OHDS. At the core of this new invention aretwo fundamental areas of discovery: 1.) a primitive retrieval operation,identified here as the BAR query, which extracts these data relationsfor the OHDS; and 2.) the ability to classify them according to how theycontribute to the construction of the OHDS.

At this point in this disclosure, it is important to point out how thesetwo discoveries relate to each other. They are, in fact, so closelyintertwined with each other, in compact “mathematical” sense, that onediscovery could not be made independent of the other. The BAR query, aprimitive retrieval operation, lends itself to the OHDS construction;and the construction of the OHDS reveals the nature of data in therelational database and how its data relations or BADR can be enumeratedand classified within four distinct, primitive types.

Clearly, these four different types of data relations or BADR occurroutinely in everyday programming, and they could be extracted from adatabase using less efficient program logic, but they could never bediscovered, let alone classified in such a systematic or unified manner,without the BAR query, and without the knowledge of their role in theconstruction of the OHDS. Therefore, the primary focus of the currentinvention is to identify these primitive data relations, using the BARquery as a scientific instrument to differentiate one type of datarelation from another, when building the OHDS.

The BAR query is an application of Burgin's theory of named sets (BNS),a mathematical primitive which is more fundamental than set theory. BNSassumes that all systems are composed of components or subsystems whichare logically related by “rules.” In the case of the relationaldatabase, the primitive SQL SELECT or BAR query enforces the “rules”between these two attributes (or subsystems), which exposes, in an exactand precise manner, four different types of data relations.

More specifically, the BAR query highlights a division of labor betweeninput and output and the two different mechanical operations each onerepresents. An input condition relies on “patterning matching” andoutput on a “naming” function which distinguishes one pool of outputdata from another. These two different mechanical operations form theunderlying basis for cycling through a chain of interrelated attributepairs recursively to build the OHDS.

The primitive data relations introduced by this disclosure occur at thedata level between two attributes or fields in a database. As indicatedabove, they could only be derived from a well-defined, carefully craftedretrieval operation, the BAR query, at the core of the inventor'srecursive mapping algorithm which builds the OHDS. The inventoridentifies the logical relationship created by the BAR query between itsinput and output a binary attribute relation or BAR. The data relationsderived from this retrieval operation are identified as binary attributedata relations or BADRs. And, the primitive retrieval operation thatexposes them, as mentioned above, is the BAR query.

With these new concepts in place, this disclosure is now able toidentify four basic types of data relations which exist in therelational model. But before proceeding to this disclosure it isimportant to point out why these data relations have gone completelyunnoticed until now. One reason for their obscurity is that the BARquery is a new art, and the data mapping from one attribute to another,using this new art, can appear to be completely unpredictable andarbitrary.

For example, in a BAR query an input condition, such COLOR=red,represents a single data value associated with the source attributeCOLOR. However, hidden under layers of abstraction in the database theremay be multiple instances of red at various record or tuple locations.At this high level of abstraction, the source code of the BAR querytreats this new input data value as an instance of one. Output from thisoperation can be one or many, depending upon the number of red locationsat lower levels of abstraction, and the number of unique data valuesassociated with the destination attribute. This means that the datamapping between source and destination attributes, or input and output,can take the form of “one-to-one” or “one-to-many,” regardless of thedatabase table declaration or the samples of data considered.

This arbitrary nature makes these primitive data relations difficult to“see” and to “identify,” particularly through the mathematical lenswhich dominates today's theoretical basis for the relational model—settheory—because it has no way of modeling it. One prominent databaseresearcher, CJ Date, has suggested that the relational model is mostlikely governed by a “new [branch of] mathematics” p. 377, but he doesnot say anything further on the matter, leaving the details about itsstructure and operations as an open question for the database researchcommunity. But from the perspective of the content menu, all of thesedata relations play an essential role in the construction of the OHDS,regardless of whether they take the form of “one-to-one” or“one-to-many” relationships. What does makes a difference is whether theBAR query output contains data-topics which are relevant to the end-useror whether this output furnishes links to something which eventuallydoes. Therefore, without the OHDS and the algorithms which support them,the discovery of binary attribute data relations could not have beenmade.

A careful analysis of the BAR query and the construction of the OHDSafforded other discoveries as well, including a more precise view of thenature of relational data, namely that it has two aspects: amechanical-value and a constructed-type, which the inventor identifiesby the concept of a meta-symbols. Pattern matching can only occur onsymbols which were encoded by mechanical values, a sequence of on/offbits. And constructed-types refer to pools of data symbols accessed by alabel or name. This new view of relational data—and all physical symbolson a computer for that matter—sheds new light on today's understandingof retrieval operations, as all of these operations can now begeneralized in an abstract fashion, regardless of the data model or datastructure.

Therefore, all retrieval operations, including the relational query SQLSELECT, can and should be viewed as an interface to an algorithm whichhas input and output. More importantly, each one of these channelsaligns itself with the phenomenon of meta-symbols: with input valuesdeployed for searchers, and output for extracting data from a pool ofvalues which has a name and which is a constructed-type. At the datalevel, this input and output functionality gives shape and form to theBADR discovered by the inventor, first by showing how they contribute tothe construction of the OHDS, with relevant constructed-types providingsibling lists and their corresponding mechanical-values providing thelinkage to a leaf node, and then by characterizing these attributes as asource and destination, which implies a logical mapping between thesetwo channels.

This input and output view of retrieval operations is consistent withthe more general concept of query mapping which refers to input andoutput schema mapping (Abiteboul et al.). However, at this new, deeperview, the mapping refers to query channels and the data and the datarelations they expose. This takes us well beyond today's theoreticalunderstanding of database queries, relational data, and even the notionof physical symbols according to Simon and Newell, as all of thesevarious concepts have never been studied together from the perspectiveof data relations.

These two refinements (input and output attributes, and query mapping atthe combined attribute and data levels) help clarify and articulate datarelations in the relational database. Until now, this area has beenunexplored by the research community. By focusing on the data mappingderived from a BAR query and the fact that this output can be either oneor arbitrarily many, these primitive data relations start to emerge andunfold when the fully formed OHDS is taken into consideration. And so,this data mapping is purely a constructed artifact which could existonly within the framework of this carefully constructed query, makingthe discovery of this primitive data mapping the subject for this newart, with the BAR query the predicate and the content menu its object.

The discovery of binary attribute data relations or BADRs provides anentirely fresh view of the data and data relations in a database, onethat lays the foundation for a more tightly integrated program logicthat improves upon the prior art in a number of significant ways. First,with the BAR query as the focal point of extracting menu data from anexternal source, the recursive algorithm that populates the OHDS is nowmore compact and efficient; it is also considerably easier to maintain.Second, now that the nature of relational data is better understood andmore precise, in terms of retrieval operations, improvements could bemade to the format of meta-query data and to the way it is collected andstored. Third, by viewing the query operation as having distinct inputand output channels, one could separate the BAR query from thealgorithms that build the OHDS, thereby enabling the same softwarecomponent, a primitive query operation, to generate menu data forruntime list menus as well.

Finally, the discoveries of the BAR and the BADR pave the way foridentifying the rules that govern attribute and data relations, and thatmake pairing two attributes possible. By clarifying these rules, newinsights about the nature of data relations can be made. One suchinsight which can be attributed to the discoveries presented here isthat semantic relations at the data relations level, as expressed by BARquery, fall into two broad categories, contextual information andconceptual linkage. Another insight focuses on how different pairs ofattributes can create different types of data relations which contributeto the construction of the OHDS.

What makes this disclosure so exceptional is the fact that the conceptof a binary attribute relation or BAR challenges a longstanding positionin the literature that advises against considering such types ofsemantic relations. In 1978, Codd, the inventor of the relationaldatabase, argued against extending any semantic analysis within arelational table at the attribute level, because he considered therelational table to be semantically “atomic” p. 413. At best, he wasambivalent about even considering such ideas, as he did not see anypoint to such speculation, at least from the perspective of arepresentational primitive in database design. Since then, no one hasbeen able to show how attributes within the same table could form anyrelevant semantic relationships that could challenge Codd's stronglyworded position. Database researchers have not even considered thepossibility that a semantic relationship could exist between twoattributes, or that two attributes could form an algebraic relationshipthat could express their underlying data relations, two specific topicswhich the present disclosure addresses in a concrete and pragmatic way,with the content menu.

Therefore, this disclosure breaks new ground by providing hard evidence,from the perspective of the inventor's content menu, that the BAR isboth useful and meaningful. At the attribute or naming level, the inputand output functions of the BAR query frame these terms in a type ofalgebra for meta-query data. At the data level, the BAR query extractsBADRs which provide essential building blocks for constructing the OHDSand conceptualizing its data-topic content as a “database taxonomy”. Atthis level of abstraction, the attribute, and its underlying data, cannow be viewed as a resource which can either describe something, such asthe attribute SIZE which can refer to small or medium data-topics, orwhich can eventually link to an attribute that provides suchdescriptions, thereby providing to means to classify attributes—andtheir data—operationally as either conceptual or operational.

At the data level, this classification is essential in showing howbinary attribute data relations or BADR characterize semantic relations,as either contextual information, when two data-symbols both describesomething, such as, “Boston” and “Massachusetts,” or as conceptuallinkage, when they eventually link to data symbols that do. And so, inthe construction of the OHD, all operational data is stripped out, inorder to only display data-symbols which serves as topics which caninform end-users about what they can expect to find in the database.Thus, one can see how these two semantic functions complement oneanother, and how the concepts of the BAR query and the BADR are mutuallydependent upon each other, in a seamless and well-integrated way, forthe discovery of their respective identities.

SUMMARY

In accordance with one embodiment of the present invention, notably therelational database, this disclosure shows how to improve the technicalcapabilities and efficiency of the authoring system responsible for theprevious art of content menu. These improvements, in turn, lay thefoundation for alternative embodiments of the authoring system which cangeneralize the discoveries disclosed here to extract lists of data fromother data models and even data structures.

DRAWINGS Brief Description of the Figures

FIG. 1 depicts the prior art of a content menu, a database interfacethat organizes database content into a menu system identified as a“database taxonomy.”

FIG. 2 depicts the client server network apparatus of the presentinvention.

FIG. 3 depicts the three software components of the prior content menu:an authoring system that generates menu data files, the menu data files,and a client browser that displays these files in a content menu.

FIGS. 4 a through 4 c depict the target database that will be used todemonstrate this new art.

FIG. 5 depicts the prior art of the open hierarchical data structure(OHDS) that organizes menu data for the content menu according to dataand data relations found in a database.

FIG. 6 depicts the OHDS storage format for the prior art.

FIGS. 7 a through 7 c depict the prior art of the developers GUI and thesoftware processes used to capture meta-query data which is then used toextract data and data relations from an external database for thecontent menu.

FIGS. 8 a through 8 c depict the new meta-query data format introducedby this new art based on the concepts of the Binary Attribute Relations(BAR).

FIG. 9 depicts the client server network apparatus of the presentinvention, showing the new software components introduced by thisdisclosure.

FIGS. 10 a through 10 c depicts the flow charts and program control ofthe algorithms responsible for exposing binary attribute data relations(BADR) in a target database according to the new teaching on BARs.

FIG. 11 is an example of the source code for a BAR query.

FIGS. 12 a through 12 d graphically depict the four different types ofdata and data relations found in BADRs.

DRAWINGS Reference Numerals

-   5—content menu-   6—list menu-   15—server computer-   18—client computer-   22—authoring system-   24—menu data file-   26—browser software-   35—external database-   68—open hierarchical data structure (OHDS)-   111—menu developers' interface-   120—binary attribute relation (BAR) notation-   140—meta-query storage format-   160—recursive algorithm-   210—BAR query-   250—binary attribute data relation (BADR)

DETAILED DESCRIPTION

An embodiment of the end-user database interface—that is identified ascontent menu 5—is depicted graphically in FIG. 1. The graphical userinterface (GUI) 5 consists of one or more nested topic list menus 6 thatdisplay the data and data relations in a database as a list of nesteddata-topic lists that take the form of a database taxonomy. Each listmenu 6, such as 9, consists of a list menu header 10, the topic selectedby the end-user in a previous list menu 8, and one or more related topicitems in the scrolling display area 11 in 9. The relationship betweenmenu header 10 and list 11 of related data-topics is significant,because it represents a primitive data relation 12, one of the fourBinary Attribute Data Relations or BADR (contextual information), whichoccurs naturally in a database structure.

In fact, data relation 12 could be derived from any type of data model,data structure, file format (including both fixed and variable lengthfields), and even RDF files, as all of the physical symbols in thesedata storage devices are composed of the same meta-symbols: a mechanicalvalue and constructed types.

List 11 of data-topics in list menu 9 of GUI 5 represents a“one-to-many” relationship with regards to the selected item in listmenu 8. The data mapping between the item selected in 8 and the list ofdata-topics in 11 is central to this disclosure because it characterizesthe BADR, a new concept that is introduced by this invention and thatwill be described in detail shortly.

In content menu 5, each time an item in list menu 11 is selected by anend-user, this technology generates a new data-topic list menu 6 thatnarrows or refines the selected data-topic according to data relationsin the database and its underlying logic. At the end of each menu path,content menu 5 displays an information object window that furnishesinformation drawn from the database. The linkage between this menu pathand the information object window is based on a primary key or a uniqueidentifier associated with each database record.

Alternative embodiments of content menu 5 include graphical interfacesthat represent nested data-topic lists in a tree-view interface and orin nested hypertext lists. Embellishments to the preferred and to thealternative embodiments of these navigation structures include graphicicons and sound clips as topic entries.

The client server network apparatus of the present invention is depictedin FIG. 2. A client computer 17 is electronically linked to a server 15.This network linkage 16 includes any combination of physical cabling andwireless connections. Server 15 is responsible for providing the menudata for the content menu interface 5 displayed on monitor 18 of client17. Client 17 has communications software that enables it to requestmenu data from server 15. An end-user on client 17 employs an inputdevice like keyboard 19 on 17 to make selections and or to input text inorder to use and navigate the content menu.

Alternative input devices on client 17 include touch-screens, pointingdevices like a mouse, voice-activated systems, and other types ofsensory input devices that would enable an end-user to make selectionsin a content menu. The monitor 18 of client 17 displays the content menuvisually as a graphic image; alternative output devices include “talkingsoftware” systems that would enable an end-user to receive auditorydescriptions of the content menu.

Alternative embodiments to the network configuration of the presentinvention include a stand-alone computer configuration where the menudata associated with the content menu resides on a local data storagedevice. Alternative embodiments to the stand-alone computer or to theclient computer 17 also include any computing device, regardless of itssize or sensory interaction, that communicates with an end-user bypresenting information actually requested by that end-user.

The major software components of the prior art of the content menu 5 aregraphically depicted in FIG. 3. One component of this prior art is anauthoring system 22 that generates menu data files 24 for content menu5. Menu data files 24 are processed by browser software 26 on client 17to create content menu 5.

In the prior art, authoring system 22 builds and maintains an openhierarchical data structure (OHDS) which organizes menu data into asingle data structure. OHDS 68 will be presented shortly in FIG. 5.Authoring system 22 employs structure 68 to generate a series ofcompiled files 24 for content menu 5, where each menu data file 24represents a network segment of structure 68. The maximum size of eachfile 24 can be set by the developer in 22, enabling the developer tocontrol the file size and thereby optimize network and serverperformance. Client browser software 26 requests a menu data file 24over the network and parses its contents to generate one or more listmenus 7 for content menu 5.

In the new art, authoring system 22 contains software tools andgraphical interfaces that enable menu developers to select and tocapture meta-query data from an external database system based on binaryattribute relations, the subject of this new art. Other capabilities andfeatures associated with this new art, which will be presented shortly,include the ability to store and retrieve meta-query data in apredefined data structure on server 15 in order to create runtime listmenus 11 in 5 on demand.

In the preferred embodiment of the present invention authoring, system22 resides on server 15 and it maintains menu data files 24 and itsmeta-query data on there as well. In an alternative embodiment of thepresent invention, say on a stand-alone system where both the targetdatabase and the browser software 26 reside on the same computer,authoring system 22 can reside on the same machine. Or it can maintainmenu data files 24 and meta-query data files on this same computer or onany other computer in the network. In other words, authoring system 22,menu data files 24, meta-query data, and the target database files canreside anywhere in a connected network.

To demonstrate the present disclosure, as well as to refer to the priorart on which these improvements are based, a relational databaseapplication that manages an inventory of books will be used as anexample. Target database application 35 includes three different tablesor entities: Books 40, Authors 50, and Publishers 60. Each row or entryin Books 40 depicted in FIG. 4 a, such as 47, represents a book in thisinventory or, in relational database terms, an instance of an entity.Each book in table 40 has data that corresponds to a Book_Title 44, anidentification number or BID 42, and a Book_Language 45. Otherdescriptive information about each book—in accordance with therelational model—is contained in the Authors 50 and Publishers 60 tableswhich have a one-to-many relation to Books 40.

At this point in the discussion, it is important to note that eachrelational table, such as Book 40, Author 50, and Publisher 60, is atwo-dimensional logical structure consisting of columns or fields androws or records. In relational database terms, these dimensions arecharacterized by attributes and tuples. The terms attributes, fields,and columns all identify the vertical dimension of this structure, andthey all can be used interchangeably without altering their meaning. Thesame is true for the terms that can describe the horizontal dimension ofthis structure, namely rows, records, and tuples.

In the relational model, columns or attributes refer to data values thatcan describe the entity, like Author 52 in 50, by the author's name.Data values in other attributes serve as value-based links betweentables, such as BID 42, a primary key, and AID 43 or PID 46 in 40 thatare foreign keys. These keys, both primary and foreign, give this modelits value-based navigation capabilities described by Atzeni et al. thatenable rows in one table to link to rows in another table.

In this new art, the functional distinction between attributes thatmanage data describing the entity versus attributes managing link datais fundamental. Attributes that are declared as primary and foreign keysin the schema, or employed in that manner, are identified in this newart as operational attributes or 48. A primary key or 48 a represents aunique data value for each tuple or row in the table. It also provides ameans to link to descriptive attribute data associated with the eachtuple and row. On the other hand, a foreign key 48 b represents a linkto a primary key that can be found in another table. Therefore, 48 a and48 b complement one another by establishing a value-based linkagebetween two two tables. All other attributes in the table structure, bydefault, are considered conceptual attributes; that is, these attributesmanage data that describes something about an entity. This distinctionbetween operational attributes 48 and conceptual attributes 49 in atable will be made throughout this disclosure.

In Codd's seminal 1970 ACM paper that introduced the relational model,he addressed this distinction between attributes, but only in a verygeneral way. This teaching stresses this distinction, by showing in veryconcrete ways how pairing two attributes together plays an essentialrole in exposing semantic relations at the data level, which theinventor identifies as BADRs. The final series of figures in thisteaching, FIGS. 12 a through 12 d, will show how data from twoconceptual attributes 49 form a distinctive type of BADR that thisteaching identifies as contextual information. In the meantime, thisdistinction between conceptual and operational attributes and theirpools of data will be raised throughout this disclosure.

Lastly, rows or, in relational terms, tuples also play a vital role inthe teaching of this new art. The row dimension of the entity structure,such as 47 in 40, 56 in 50, or 66 in 60, serves as a fundamental way fora data value in one attribute to relate to a data value in another,particularly from the perspective of retrieval operations. In fact, thecentral teaching concerning the binary attribute data relation reliesextensively on this dimension, and on the pairing of two attributes, toexpose this data relation. Prior to this disclosure, no one hadconsidered how these two dimensions—attributes and tuples—in therelational database table interacted. Therefore, by considering thesimplest case, namely two attributes in a BAR and the tuples or rowsthat form a bridge between them, the inventor is able to identify andclassify the data relations that are responsible for construction of theOHDS and for the database taxonomy displayed in content menu 5.

A graphic representation of the prior art of the open hierarchical datastructure or OHDS 68 (a. k. a. the K2Structure) is depicted in FIG. 5.As mentioned in the Background section, OHDS 68 manages menu data forcontent menu 5, and its organization is similar to the LEFT child-RIGHTsibling structure described by Knuth. However, in order to build andmaintain OHDS 68, authoring system 22 manages dedicated interactive,graphical user interface that enables developers to add and modifytopics by hand. Other tools in authoring system 22 populate structure 68automatically by mapping data and data relations in a target database,such as 35, directly to leaf nodes in 68. Lastly, the fact that anybranch or leaf node in 68 can have more than one parent distinguishesthis structure markedly from the one described by Knuth.

Flow in structure 68 starts at root node 70 and continues downwardthrough one or more branch nodes, like 71 or 72, to a leaf node like 89or 92 that links to an information object. Each node in structure 68 canhave two different pointers that directly correspond to each list menu 6in 5. A sibling pointer on a node, such as on node 73, establishes thebasis for a list of data-topics that directly corresponds to a list ofmenu items, like 11 in 9 when sibling pointer on 93 is taken intoconsideration. Each node in 68 also has a child pointer that gives thisstructure its distinctive hierarchical flow. In content menu 5, thisedge establishes the downward linkage and flow from list menu 8 to itssuccessor list menu 9 or from list menu 9 to an information objectwindow based on value A associated with node 93. At the end of each pathin structure 68, any leaf node can link to the same information object,like 92 and 94.

Database structure 104 managed by authoring system 22, depicted in FIG.6, stores menu data associated with content menu 5 according to thehierarchical organization depicted by 68. Data associated with each nodein 68 are stored in attributes such as TOPIC 106 and NODE 105. Each rowin 104, like 110, represents a specific node in 68, such as the rootnode 70. Alternative embodiments of storing menu data associated withstructure 68 include predetermined file formats, as well as other typesof database architectures or file and directory structures.

Lastly, database structure 104 provides the framework for compiling menudata into one or more menu data files 24 for the content menu 5. Analternative embodiment of such compiled data files 24 includes the newart disclosed in this teaching, which shows how to generate a list menu6 at runtime using meta-query data that will be presented shortly inmore detail with the description of FIGS. 10 b and 10 c.

An overview of the prior art of the developer's graphical user interface111 and the program flow of meta-query data is displayed in FIGS. 7 athrough 7 c. These figures show how this interface captures meta-querydata associated with target database 35, and how this prior art storesand uses meta-query in authoring system 22 to create structure 68 in104.

The first figure of this series, FIG. 7 a displays the menu interface111 employed by a menu developer to capture meta-query data. In 111, thedeveloper selects an item in each scrolling list menu, like DisplayColumn 112, to identify and capture meta-query data from externaldatabase 35. These selections constitute the meta-query data that isthen applied to the mapping algorithms which extract data and datarelations from target database 35. For instance, the selections made in111 would be responsible for furnishing meta-query data that isresponsible for displaying publishers' names in scrolling list 11 inlist menu 6 of 5 that would refer to data values in Pub Name 62 ofPublishers 60.

It is important to note that interface 111 requires the developer toselect the names of two attributes, a display column 112 and a linkcolumn 113, each time the developer connects to a table data source. Thedisplay column 112 serves as a source for the data-topic values aredisplayed in a list menu 6 of content menu 5. The second attribute, linkcolumn 113, associates link values with each data-topic in 112. Both thedisplay column 112 and link column 113 selections serves as meta-querydata used by authoring system 22 to generate structure 68 and runtimelist menus 7 in content menu 5.

Interface 111 also captures other types of meta-query data. Thisincludes built-in functions, keywords, and schema labels in field 114which can control how output data is formatted and displayed, and anyconditional clauses in field 115 which can add more precision to aselection condition.

The flow of program control from interface 111 to structure 68 in 104 isdisplayed in FIGS. 7 b and 7 c. Program flow 116 in FIG. 7 b starts withinterface 111 and culminates with authoring system 22 depositingmeta-query data in structure 118 from the coded expression 117. Programflow 119 in FIG. 7 c starts with program logic in authoring system 22that accesses meta-query data in 118 to extract data and data relationsfrom target database 35 that it will use to populate structure 68 indatabase structure 104.

FIGS. 8 a through 8 c depict the notation for the Binary AttributeRelation (BAR), its correspondence to a database entity, and how it isstored and managed on computer 15 by authoring system 22 as meta-querydata in 118. It should be noted that in this new teaching on meta-querydata the BAR represents a pair of attributes that function as input andoutput channels in a BAR query. From this perspective, the BAR notationalso represents a compact way to consider a unit of meta-query that canbe stored with other units of meta-query data. Mapping algorithms thatextract data and data relations from 35 employ this meta-query data tobuild the BAR query; please refer to FIG. 11 for the details.

In both the BAR and the BAR query, the pair of input and outputattributes represent a logical relationship which is based on the factthat both attributes have something structurally in common. In therelational database, that commonality is defined by the tuple or row. Inother data sources, such as other data models, data structures and datafiles, that commonality can be rows, records or any other types ofstructural elements which would allow two attributes, columns or fieldsto overlap structurally with one another. Yet, no matter what thetechnical setting, there is another, more striking commonality, namelyretrieval operations.

Because all retrieval operations employ pattern matching on mechanicalvalues associated with an input channel, and some type of designationfor output, such as an attribute name or label or a field location oridentifier which distinguishes one pool of data from another, suchretrieval operations can easily be abstracted and generalized, givingrise to the BAR query as a primitive retrieval method. In other words,the BAR query is composed of an input clause, an output clause, and avariety of interchangeable keywords, logical symbols, structuralreferences to data systems, and syntax which could be represented, in anabstract way, by any query or retrieval language, effectively enablingthis simple concept to be generalized and considered a universal dataaccess method.

In the relational database, the BAR query employs pattern matching onmechanical values managed by the input attribute to locate all relevanttuples. When there are redundant values at the intersection of the inputattribute and its tuple instances, this retrieval operation returnsmultiple tuples. Using a single data value as a test condition on theinput attribute—one can observe output data values which span acrossmultiple tuples. In this setting, the mapping between this new inputvalue and its output yields a one-to-many pattern. In other settings, asingle input value returns a single tuple, and the mapping yields aone-to-one pattern. By exploiting the mechanical features of physicalsymbols, and by applying this knowledge to retrieval operations, the BARquery is able to capture the arbitrary nature of such data relationsbecause its functions are mathematically and logically aligned with thestructure of the relational table, in a precise and accurate manner.

The first figure in this series, FIG. 8 a depicts the formula for aBinary Attribute Relation or BAR 120. The left and right parenthesisdefine a logical relation that binds the two elements. In this case,these two elements represent variables: an input attribute A_(i) 122 andan output attribute A_(o) 124. Each variable in this formula stands infor an attribute label or heading that was declared in the databaseschema.

Operationally, these two elements represent two attribute labels whichare applied to a BAR query as an input attribute and as an outputattribute. In the Structured Query Language (SQL) SELECT demonstrationof this invention, which will be presented shortly in detail in FIG. 11,these two attribute labels represent the primary components of a BARquery. Input attribute 122 is applied to the formation of an inputclause, such as “WHERE A_(i)=v” (where v is a data value in A_(i)) and124 specifies an output channel or A_(o).

In other embodiments of this retrieval function, the input attribute 122is a field name or numeric identifier for a field or column in a seriesof fields and columns. Input attribute 122 specifies the subject for atest condition in a non-relational database or data structure or file,with the logical concept of equality representing the predicate and atest condition value being the object. In these alternative embodiments,input 122 can refer to a location or structural element in the targetdata system, in which case the BAR query refers to an input-outputinterface to an algorithm or computer program that does pattern matchingon 122 and returns output data values based on 124.

The next figure in this series, FIG. 8 b, depicts a BAR formula 130using variables for an attribute label or field name in a databaseschema, like 44 for 122 or 43 for 124, preceded by entity or objectlabel 132. In BAR formula 130, the entity name prefix 132 corresponds tothe name or label that would be used to access an entity or object. Forinstance, Book 40 of 35 in FIG. 4 a would be an example of such anentity label, which, in this example, is a schema label for a relationaltable. When the an entity label applied to BAR 120 on the left below, ittakes the form of BAR 130 on the right,

(Language, Title) (Book.Language, Book.Title).

The last figure of this series, FIG. 8 c, graphically presents anoutline of storage structure 118 that manages the meta-query data. Thisnew meta-query storage art introduces a new format 140 which is based onBAR 120 (and 130) and on the source code of the BAR query in FIG. 11.Program control in authoring system 22 enables a content menu developerto navigate over target database 35 using a graphical menu interface 111to create BAR 130 by selecting items in scrolling regions 112 and 113.Interface 111 now captures BAR 130, along with any related meta-query in114 and 115, and stores them in structure 118. Each BAR 130, and itsrelated meta-query data 142, is stored in a predefined sequence: aninitial entry 141, one or more successor entries like 144, and a finalentry like 146, which can be accessed by various means including ansequential index.

An alternative embodiment of structure 118 depicted in FIG. 8 c stores asingle attribute for each unit of meta-query data, by telescoping achain of interrelated BAR pair. This technique eliminates redundantmeta-query data is identified as the “Short-Form” of BAR 120, whichemploys its own specially-designed algorithms to reconstruct a chain ofinterrelated BARs.

In the next diagram, FIG. 9 presents a graphical image of the clientserver apparatus of the new art, along with the software components thatsupport these new capabilities. On server 15 this includes sessioncontroller 155 that managers the individual sessions associated witheach client 17. In turn, each client 17 has a cookie 150, software thatmaintains information on the individual end-user navigation on thecontent menu 5, including a session ID that distinguishes one clientsession from another. The software cookie 150 maintains persistent dataon the session, such as the start-time stamp, the current list menu 6 in5, as well as other parameters and metrics related to the end-usersactivities on 5. Browser software 26 on 17 is responsible for furnishingsome of these parameters, and session controller 155 on server 15maintains others.

On client 17, browser software 26 in this new art is capable ofgenerating a list menu 6 for content menu 5 deploying two differenttypes of menu data files 24: compiled and runtime files. Both types offiles 24 include menu data for one or more list menus 6 in a contentmenu 5. The compiled menu data file 24 is generated during a productionrun using OHDS 68 in structure 104 to generate one or more data file 24.These files can be built anywhere, and they can be stored on server 15or on another computer that is accessed by server 15.

The compiled menu data file 24 has the advantage over runtime 24 ofconserving network resources, at the expense of delivering static andpossibly out of date data. It is built prior to any formal request formenu data made by browser software 26 on 17. In contrast, a runtime menudata file 24 is generated on demand, when a request for specific listmenu data is made by browser software 26 on 17. The runtime 24 contains“live” data.

In the next series of figures, FIGS. 10 a through 10 c depict theprogram control that builds a BAR query, at runtime, for the algorithmthat extracts data and data relations from target database 35. Programcontrol in the authoring system 26 establishes and maintains aconnection to 35 in order for the developer to use interface 111 and forthe program control in authoring system 22 to retrieve data from 35.

In this new art, FIGS. 10 a and 10 b represent the program control forcreating the two different types of menu data files 24: runtime andcompiled. In both instances, the algorithms which generate these twodifferent menu data files use the same meta-query data, even though onelist menu 6 in content menu 5 may display “live” or runtime data-topics,and another 6 in 5 displays data-topics which were “static” or stored ina menu data file 24 which was compiled at an earlier date. The lastfigure in this series, FIG. 10 c, shows how the BAR query is constructedand executed, and how the results are returned to the calling program.

The first figure in this program control series, FIG. 10 a depictsprogram logic 160 that builds OHDS 68 in 104 that provides the frameworkfor generating compiled menu data files 24. Authoring system 22 builds68 in 104 on demand or at scheduled production time. After system 22builds 68 in 104, another software system in 22 traverses 68 in 104 togenerate and to compile one or more menu data files 24, according to aprescribed optimal file size configured by the developer. Each compiledfile in 24 contains at least one list of nested data-topic lists thatdescribe instances of the entity in database 35.

Authoring system 22 calls ‘BuildK2’ 160 and starts the recursion bypassing a node value in 104, like node 70, an index into BAR structure118, and cmd, a conditional command string that eliminates any unwantedvalues, such as the NULL value. At 162, routine 160 initializes localprogram variables. Next, program control, at 163, calls fetchBADR thatcan be found in FIG. 10C to extract a list of data from 35.

Each time routine 160 calls fetchBADR 200 at 163, program logic at 164and 166 checks on the type of data returned by 200. If these data valuesrepresent operational data, that are used to link two tables or that canidentify a tuple, then the results are treated differently fromconceptual data, which are used as data-topics in 5. This operationaldata is used as value-based links, which are used to reach conceptualdata or to link to a tuple for displaying an information window. Thisdistinction between conceptual and operational data is generalizedacross the input and output in a BAR to classify data relations or BADRfound in the database by the way they are used by the database and bymapping algorithms in authoring system 22 in building an OHDS 68.

When routine 160 determines at 164 that fetchBADR returns a dataListthat represents operational data associated with attribute 48, it nexttests, at 165, if these values represents primary key 48 a functionally,which would signify the final BAR index. If so, routine 160 callsAddLeafNodes to add a sibling list of leaf nodes to structure 68 in 104.Otherwise, the operational data in dataList refers to data values thateventually link to conceptual data. In this case, routine 160 callsFilterOA at 167 to cycle through this operational data in order toeventually reach conceptual data that can be used as data-topics incontent menu 5.

When fetchBADR returns a dataList that represents conceptual data, orlist of data-topics that functions that way, routine 160 callsAddSiblingList at 169 to create a sibling list in 68. Next, 160 updateslocal variables and makes a recursive call to itself at 172. Uponreturning, 160 checks if the current node or n in 68 has a sibling, andif it does, 160 updates the cmd string to include the new inputcondition based on the current n, and then calls itself to continue itsdepth-first tree-growing pursuit of OHDS 68.

In the next figure in this series, FIG. 10 b displays program control180 that is used to generate a runtime list menu 6 in content menu 5.Session controller 155 on server 15 calls runTime routine 180 and passesthe sessionID associated with the cookie software 150 on client 17 alongwith the request made by the browser software 26 on client 17 thatincludes the BARindex or vector in 118 and the selection conditions. At182, routine 180 initializes the program control variables including theinput and output clauses which are applied to the BAR query. At 184,routine 180 calls fetchBADR 200, displayed in FIG. 10C, to build thesource code for a BAR query and execute it.

At 186, program control in 180 determines how to employ the dataListreturned by fetchBADR. In this regard, routine 180 either sends dataListback to the calling software browser 26 on 17 to create the next listmenu 6 in 5 or it treats this data as representing operational data. Asmentioned in the last figure, operational data links to data thatdescribe an entity or it signifies a primary key that can be used tocreate a window object which displays information about the string ofdata-topics selected by the end-user. At 188, if this operational datarepresents a primary key 48 a, then routine 180 calls infoWindow at 190to build and return a window object to the browser 26 based on thatprimary key. Otherwise, routine 180 cycles through the operation datalists by calling filterOutOA at 192 till it reaches conceptual data.

The essence of new program control in 160 and of the new meta-queryformat 140 is presented in FIG. 10 c. Here, the fetchBADR routine 200builds the source code for the BAR query; executes the BAR query against35; and returns the results to routine 160. These results are usedeither to build OHDS 68 in 140 in order to compile a series of menu datafile 24, or they are used by routine 180 to create a runtime menu datafile 24.

At the start, routine 200 initializes local program variables at 202.Next, at 204, routine 200 builds the command string and executes theretrieval operation against target database 35. And, finally, at 206,routine 200 parses through the results of this retrieval operation andreformats them for the calling procedure.

The actual source code string for the BAR query that routine 200 createsis treated in an abstract manner at 204 as having an “output clause” andan “input clause” along with the keywords, SELECT and WHERE, whichunderscore the syntax of the query which performs the data extraction.In this example, the data extraction is executed by a relational engine,and the SQL syntax is used to demonstrate a BAR query. In alternativeembodiments of the invention, the keywords, syntax, and even its inputand output clauses may be entirely different. For instance, routine 200could generate query source code for a hierarchical database, or even analgorithm build to extract data from a field-oriented file based onsequence or fixed locations. In these alternative embodiments, routine200 essentially generates code for a predefined access method, executesit, and returns the results to the calling routine.

Finally, FIG. 11 presents an example of one type of BAR query sourcecode that could be constructed by a routine like 200. This particularsource code, depicted here in SQL, the universal data manipulationlanguage associated with the relational database, represents a primitivequery operation which pairs a single new data value with a attributealong with any prior selection conditions in 214.

The first time that routine 200 is called this source code exemplifiesthe theoretical simplicity of the BAR and the BAR query. However, witheach new recursive call, each new input attribute/value pair, or“A_(n)=v_(n)”, is concatenated with the prior input conditions in orderto extract the logically correct subset of BADRs that exist between thetwo attributes in the current BAR. Therefore, one can and shoulddifferentiate a simple BAR, as truly having a single input attribute or“A_(i)=v” where A_(i) is that attribute and v is a data value that canbe found in A_(i), from an operational BAR. An operational BAR, wherelike the one presented at 210 in FIG. 11, the source code has a single,new input attribute/value pair, “Book_Language=“English” which isconcatenated to input_clause 214, which includes one or more previousinput attribute/value pairs representing each level of recursion torecreate the proper logical context, e.g., “((Book_Language=‘English’)AND (A₂=v₂) AND (A₁=v₁))”.

The source code in 210 shows the components of the preferred embodimentof a BAR query in a SQL SELECT, and just how easily this can begeneralized across other query languages. Source code 210 is composed ofkeywords 212, symbols 214, and a syntax (a prescribed sequence ofkeywords and symbols) that designates an input clause 225 and an outputclause 220. In this regard, it is important to note that in spite of itsuniversal status SQL still has multiple dialects that can impedeportability; but with a BAR query implementation, i.e., by simplifyingthe query language elements to input and output, even these subtle, yetannoying language differences can be avoided completely.

After seeing the simplicity of these BAR query components, it should benoted, once again, that alternative embodiments of routine 200 cangenerate source code for any retrieval service which can be used toextract data values from a target data system. That is because all ofthese data systems essentially use labels, names, numbers, and evenstructural locations to differentiate one pool of data from another. Andbecause such a retrieval operation, including an interface to analgorithm, essentially treats one pool of data as input and another asoutput. Therefore, the SQL SELECT statement in FIG. 11 presents just oneexample of how to create a BADR or mathematical relationship between onepool of data and another.

And now, in the last series of figures, FIGS. 12 a through 12 d depictthe four different types of data relations that can be expressed by aBAR query, such as 210 in SQL. These different types of data relationsrepresent the complete set of binary attribute data relations or BADR250 derived from a BAR query. In each instance, a data value v specifiesa condition on an input attribute in BAR 120 or A_(i). To fully exposeBADR 250, this data value represents an existing value in the inputattribute, such as the data value that can found at intersection of 45and 47 in 40. This input condition, A_(i)=v, regardless of thepossibility of deeper logical context, is responsible for creating theone-to-one or one-to-many relationship with the output data returned byBAR query, where both input attribute 122 and output attribute 124 aredrawn from the same entity.

The relationship between v and its output data is logically (and somemight say mathematically) based. Throughout this disclosure, thislogical relationship is the binary attribute data relation or BADR 250represented in the FIGS. 12 a through 12 d. The discovery of this datarelationship was made possible by observing the construction of OHDS 68,which has been shown to use two different types of data: conceptual andoperational data values, as evidenced by program control 188 in 180.

This new art advances the understanding of meta-query in two crucialways: 1.) by focusing on pairs of attributes that serve as input andoutput in a primitive BAR query, and 2.) by treating all relational dataas capable of serving as a link to other data within the same tuple orrow structure. This new view of linking data in one attribute to anotherby way of their commonality, namely tuples and rows, was and isunconventional.

Other unconventional approaches to relational data employed by theinventor exploit the fact that retrieval operations use pattern matchingon mechanical values and output declarations based on constructed types,which effectively means that retrieval operations on allentities—regardless of the data model—operate on all physical symbols inthe same manner, at a meta-level. Therefore, the inventor asserts thatrelational data, and all symbolic data in an entity for that matter, iscomposed of two meta-symbols: a mechanical value and a constructed type,and this highly original view of relational data enables the sameattribute to work equally effectively as input or output in BAR query.It also enables the inventor to view the relationship between data andits attribute declaration in a strictly pragmatic manner, allowing himto ask how attributes and data contribute to what the end-user sees inthe content menu.

From this new perspective, FIGS. 12 a through 12 d show all thedifferent ways that conceptual and operational attributes—and theirrespective conceptual and operational data—can be paired together, thuscreating an opportunity for classifying BADR 250 according to thesepairings. Table 1, listed below, summarizes all these possiblecombinations of attribute types as meta-query data that can occur in BARnotation 120. This table employs the following intuitive notation: C forconceptual attribute 49 and O for operational attribute 48.

Early in this specification, the disclosure made a point ofdifferentiating one type of attribute from the other based on how eachattribute in the schema was declared. Once again, we are reminded thatconceptual attributes 49 typically manage data values that can be usedto describe an entity, and operational attributes 48 typically managedata that serve as links between entities, giving the relational modelits distinctive value-based approach as described by Atzeni et al.

The first entry in Table 1, (C, C), designates a special type of datarelation 250 that the inventor identifies here as ContextualInformation, where—from the content menu end-users perspective—onedata-topic selection leads to another list of data-topics according tosome, yet to be determined underlying logic that governs the formationof the relational table and other types of entities. Sometimes thislogic is self-evident, for example, when the cities of Amherst andConcord follow the state of Massachusetts. At other times, this logiconly makes sense from the perspective of the database application andthe end-users' expectations, say when “January” or “February” followsthe selection of “New England” in a sales tracking application.

The other designations in Table 1, namely (C, O), (O, C), and (O, O),all refer to the ways that the relational model creates links toContextual Information. Therefore, it is identified here as ConceptualLinkage. These types of BARs represent data relations that either linkto another table, (C, O), or link from another table, (O, C), orrepresent pairs of keys in a table, (o, O), that represent many-to-manyrelations.

TABLE 1 BAR Represents (C, C) Contextual Information (C, O) ConceptualLinkage (O, C) Conceptual Linkage (O, O) Conceptual Linkage

With this classification of binary attribute relations in place, thenext step entails looking to see how these relations correspond to theformation of binary attribute data relations 250, and they contribute tothe formation of a content menu.

The first figure in this series, FIG. 12 a representsconceptual-to-conceptual attribute pairing or (C, C). As mentionedearlier, this type of BAR—at the data level—depicts contextualinformation and a specific type of BADR 250 identified here as 252. BADR252 is a fundamental building block of the database taxonomy, because itfurnishes the lists of data-topics that end-users see in content menu 5.In this instance, the data and data relation created here are drawn fromtwo conceptual attributes that manage data values that can be used todescribe an entity.

From the end-users' perspective, the content menu displays thisrelationship between two conceptual data-topics to help them move closerto the information they seek. Data values extracted from an outputattribute serve as data-topics in list 11 of menu 9; the input datavalue serves as a link to a prior list. Operationally, each end-userselection in content menu 5 formulates a new condition for thedata-topic display in the next list menu 6. The selected data-topic isapplied to next BAR 120 as input v to 122. From content menu 5, therelationship between the data-topics in one list menu 6 and the next 6is both operational and semantic, or—in more practical terms—it is bothuseful in creating a context for the end-user.

In the example displayed in FIG. 12 a, the list of book titles thatfollows after selecting “English” from the previous list highlights thesemantic relation between these two lists, which is identified here ascontextual information. When progressing from the list of languages to alist of relevant book titles, the flow is natural, making the process oflooking up a book in a content menu 5 intuitive. Clearly, the BAR querythat exposed this BADR 252, and the recursive algorithm that establishedthe links between one list of data-topics and the next, enables contentmenu end-users to view database content in a powerful, new format thatis innovative, yet familiar because it is similar to an index which canbe found in the back of a book.

Other combinations of attribute pairings include conceptual andoperational attributes, such as (C, O), (O, C), and (O, O), thatessentially serve up BADRs 250 which eventually link to other conceptualdata or a primary key 48 a in a final table destination. Examples ofthese types of attribute pairs can be found in FIGS. 12 b through 12 d.

For instance, FIG. 12 b depicts a relationship between a conceptualattribute and an operational attribute or (C, O). Thisconceptual-to-operational data relation is depicted at the data level byBADR 254. In this example, ‘German’, a data value from attribute 45 in40, a conceptual attribute 49, maps to ‘1023’, operational data from 43in 40, a foreign key 48 b. A BADR 254 could also map to a primary key 48a, such as BID 42 in 40. In either instance, the conceptual data bindswith operational data to establish a value-based linkage between twoattributes within the same entity to characterizes BADR 254 as abuilding block in a network of data and data relations which spans fromone entity or table to another.

In FIG. 12 c, the conceptual and operational attribute pairing isreversed, i.e., (O, C), to create another type of BADR 250, anoperation-to-conceptual data relation 256. Once again, the operationalattribute in this pairing can represent either a primary key 48 a or aforeign key 48 b, depending upon on how this building block is employedin creating a network of data relations. In the example depicted in thefigure, the operational attribute happens to depict conceptual linkageinvolving a foreign key 48 b, 46 in 40, and the conceptual attribute 44in 40.

And, finally, the consequences of an operation-to-operation BAR, or (O,O), are depicted in FIG. 12 d. This type of BADR 250 represents a pairof operational attributes within the same entity. This figure representsthe pairing of two foreign keys 48 b. It characterizes a particular typeof entity found in the relational model, a many-to-many table.Alternatives to this pairing include a primary key with a foreign keyand a foreign key with a primary key.

GLOSSARY

BAR query—a primitive retrieval operation in a recursive algorithm whichinitially starts out with a single input and output channel, and whichadds a new condition with each new iteration. In the preferredembodiment of the present invention, the relational database, eachchannel represents a table attribute or field. In alternativeembodiments of the BAR query, say a predefined query language interface,such as program control or a program interface on a data system, theinput and output channels can be represented by a symbol or anexpression.BAR or binary attribute relation—a logical relationship between twopools of data in a data system, which is expressed by a primitiveretrieval operation. This term can also be used to describe a logicalrelationship created by a retrieval algorithm between two pools of datain one or more systems that are used to manage data, including file anddirectory systems.BADR—a binary attribute data relation is a primitive data relationderived from a BAR query. It consists of a source data value in a poolof data and one or more data values from a destination pool of data.conceptual attribute—any pool of data whose values can describe aproperty of an entity that is modeled by a data system.conceptual data—a data value which describes a property of an entitywhich is being modeled.conceptual linkage—a logical relationship between two pools of datawhich occurs at the data level, where a data value in a source poolrelates to one or more data values in a destination. Data associatedwith the source, destination or both represents data that can be used asvalue-based links.constructed-topic—a topic in a list menu of a content menu that wassupplied by a menu developer by hand.constructed type—an aspect of a physical symbol on a computer whichrefers to its membership in a pool of data. A label or a symboliclocation, including an index, can be used to distinguish one pool ofdata from another.content menu—a graphical user interface (GUI) consisting of nested listmenus, or equivalent isomorphic structures such as a tree-view, whichdepicts data-topics and their relations in a data system in the form ofa database taxonomy.contextual information—a semantic relationship which takes the form of a“IS A TYPE OF” predicate, where a data value in one pool relates to oneor more data values in the second.database—a data system composed of one or more pools of data whichconstitute an entity, and where one or more of such entities bysupported by integrated retrieval operations.data object—a pool of data in a data system. In a data system, like arelational database, each table attribute or field represents a dataobject.data structure—a very basic data system which manages data on a computeraccording to some predefined arrangement of data values.data-symbol—a data value drawn from a pool of data and displayed in alist menu of a content menu.database taxonomy—the knowledge representation of data and datarelations in a database which is accessed interactively by a contentmenu.data-topic—any data value drawn from a pool of data in a data systemwhich can displayed in a content menu.data system—a computer software system that is used to manage acollection of data. Such systems can range in scale from the simplicityof a computer file or directory system—consisting of uniform divisions,subdivisions, and fields within those subdivisions—all the way up to thecomplexity of the relational database management system (RDBMS).mechanical value—an aspect of a physical symbol on a computer composedof a pattern on/off bits which enable the computer to make logicalcomparisons between two physical symbols.meta-query data—any data which is either selected or supplied by menudevelopers and used to construct source code for a BAR query.meta-symbol—an aspect of all physical symbols on a computer whichentails physical values to differentiate one symbols from another, andmembership properties, which distinguish one pool of data from another,with the former representing its mechanical-value and the latter itsconstructed-type.operational attribute—a pool of data in a data system which providesvalue-based linkage to an entity. In a relational database, it is atable field which has been declared as a primary or a foreign key.operational data—any data value which can be used to link one entity toanother within a data system. In the relational database, operationaldata is represented by any attribute that has been formally declared inthe schema as either a primary or foreign key.physical symbol—a symbol on a computer which is encoded by a series ofon/off bits and which is accessible to an observer by visual or byauditory means.primitive data relation—the data mapping between two pools of data in adata system which is derived from a primitive retrieval operation, andwhich represents a “one-to-one” relationship or a “one-to-many”relationship.relational data—a data value managed by the logical structure of arelational database table.value-based linkage—the type of linkage that is based on mechanicalvalues of physical symbols.

CONCLUSION

This concludes the description of an embodiment of the invention. Theforegoing description of the embodiment of the invention has beenpresented for the purpose of illustration and description. It is notintended to be exhaustive or limit the invention to the precise formdisclosed. Many modifications and variations are possible in light ofthe above teaching, including software methods which would use memoryand program logic in be less efficient manner and which would takelonger to execute because they are not as mathematically precise andaccurate as this teaching. Therefore, the scope of the present inventionis not intended to be limited by the specific examples presented in thisdetailed description, but rather by the claims appended hereto.

1.-18. (canceled)
 19. A computer software system which provides themeans for establishing a primitive data relation between two dataobjects in a system of data objects comprising: the means for capturinga unit of meta-query data associated with said system of data pools, themeans for storing and retrieving said unit of meta-query data associatedwith said system of data pools from a predetermined storage device, themeans for constructing a query statement, which merges said unit of metaquery data with an element of a predefined query language, and which,upon execution of said query statement, said computer software systemreceives values from said system of data objects, whereby, saidprimitive data relation serves as an essential component in theconstruction of a content menu, which enables a nontechnical end-user toview data-symbol content in said system of data objects.
 20. Thecomputer software system of claim 19 wherein said computer softwaresystem is implemented in a computer language which is compatible with atleast one computer system.
 21. The system of data objects of claim 19wherein said system of data objects is implemented in a computerlanguage which is compatible with at least one computer system.
 22. Thesystem of data objects of claim 19 wherein said system of data objectshas a structure which is compatible with at least one data model andwith at least one data structure.
 23. The query statement of claim 19wherein said query statement is implemented in a computer language whichis compatible with said system of objects.
 24. The series of meta-querydata of claim 19 wherein said series of meta-query data is compatiblewith the computer language elements of said query statement.
 25. Thecontent menu of claim 19 wherein said content menu displays at least onedata-symbol in at least one type of graphic display.
 26. The primitivedata relation of claim 19 wherein the said primitive data relationrepresents a semantic relationship between a single, new input querycondition on a source pool of data and a list of output values on adestination pool of data.
 27. The semantic relationship of claim 26wherein said semantic relation represents contextual information betweensaid single new input query condition and said list of output valueswhich describe something about the content in said system of dataobjects.
 28. A computer software system which provides the means forestablishing a primitive data relation between two data objects in asystem of data objects comprising: the means for capturing a unit ofmeta-query data associated with said system of data pools, the means forstoring and retrieving said unit of meta-query data associated with saidsystem of data pools from a predetermined storage device, the means forconstructing a query statement, which merges said unit of meta querydata with an element of a predefined query language, and which, uponexecution of said query statement, said computer software systemreceives values from said system of data objects, whereby, saidprimitive data relation serves as an essential component in theconstruction of a content menu, which enables a nontechnical end-user toview data-symbol content in said system of data objects.
 29. Thecomputer software system of claim 28 wherein said computer softwaresystem is implemented in a computer language which is compatible with atleast one computer system.
 30. The system of data objects of claim 28wherein said system of data objects is implemented in a computerlanguage which is compatible with at least one computer system.
 31. Thesystem of data objects of claim 28 wherein said system of data objectshas a structure which is compatible with at least one data model andwith at least one data structure.
 32. The query statement of claim 28wherein said query statement is implemented in a computer language whichis compatible with said system of objects.
 33. The series of meta-querydata of claim 28 wherein said series of meta-query data is compatiblewith the computer language elements of said query statement.
 34. Thecontent menu of claim 28 wherein said content menu displays at least onedata-symbol in at least one type of graphic display.
 35. The primitivedata relation of claim 28 wherein the said primitive data relationrepresents a semantic relationship between a single, new input querycondition on a source pool of data and a list of output values on adestination pool of data.
 36. The semantic relationship of claim 35wherein said semantic relation represents contextual information betweensaid single new input query condition and said list of output valueswhich describe something about the content in said system of dataobjects.